型付き API リクエストを実現するいくつかの手法とその選択 | TSKaigi Kansai
スピーカー
株式会社ドワンゴ
コードファーストなAPI 連携
API仕様書
仕様と実装が関連づく、型により守られる
API仕様との乖離を防げる
結合テスト
型で表現できるレベルのテストケースは省略可能になる
監視
TypeScriptファーストな手法
BEとFEで型定義の共有
モノレポを前提
フレームワークの機能を使う
tRPC
1. 型定義の共有
サーバ側の型定義をexport
Client側でfetchする際に使う
Pros
簡単に始められる
Cons
assertしてるだけでレスポンスの型は保証されない
Zodスキーマの共有
typeを定義して、satisfies ZodType<HogeType>すると型の2重管理を防げる
3. フレームワークの機能の利用
Honoなど
Pros
コードの共有から小さく始めやすい
フレームワークの機能に乗れると高速に開発ができる
Cons
TSに強く依存
片方が別の言語になると・・・
OpenAPI
サーバーのコードからOpenAPIを自動生成する
言語非依存
仕様が標準化されてる
エコシステムが成熟
既存の実装を損なわずに採用できるケースがままある
なぜOpenAPI？
gRPC
HTTP/2が必要
プロトコルバッファの表現力
Go以外エコシステムがあまり成熟していない
GraphQL
そもそもが根本的に難しい
BEの実装負担
既存実装をGraphQL化しづらい
OpenAPIと実装を繋ぐ手法
サーバーコードからOpenAPIを自動生成
NestJS・Hono・FastAPIなど
サーバー実装からOpenAPIを生成することの是非
Pros
仕様と実装が一致する
常に最新になる
OpenAPIを手書きしなくて済む
Cons
実装を変更しないとOpenAPIを変更できない
変更予定のAPIをうまく表現できない
OpenAPIからAPIクライアントを生成するライブラリ
openapi-typescript、openapi-fetch
OpenAPIからサーバコード生成
TSではメジャーなものはない
OpenAPIはyamlを手書きするの？
TypeSpecが便利
まとめ
サーバとクライアントのコード共有はリスク
結合レイヤはエコシステムが充実しており、OpenAPIが良さそう
OpenAPIとの乖離はテストケースを書いて頑張る
テスト用のクライアントコードをOpenAPIから生成する